
PROVIDING VCR FUNCTIONALITY 
FOR DATA-CENTERED VIDEO MULTICAST 

BACKGROUND AND SUMMARY OF THE INVENTION 

5 The present invention relates generally to video on-demand 

multicasting. More particularly, the invention relates to a technique for 
providing VCR functionality (e.g., play, pause, fast forward, rewind, 
jump) in a data-centered video multicast or broadcast network. 

Video on-demand service promises to create an entire new 

10 dimension in home entertainment possibilities. Whereas current pay- 
per-view broadcasts are confined to specific broadcast times, video on- 
demand relaxes adherence to strict schedules. Customers are able to 
request a specific video, selected from a database of choices, and 
have the video delivered essentially instantaneously or, in the worse 

1 5 case, after only a brief delay. 

It is recognized that most requests for videos are from a small 
group of the currently most popular movies. Using multicast to send 
these movies is an efficient way to satisfy customer demand. Currently 
there are two basic approaches to providing multicast video on- 

20 demand. In the user-centered approach, the server allocates channels 
to one user or to a group of users and then sends the movie over the 
allocated channel or channels. In early unicast systems (a special case 
of multicast, with one user per group) a single channel was allocated 
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for each user. More recent multicast systems allocate one channel to 

support several users. 

In the data-centered approach, the server allocates channels to 

a movie or to a part of a movie. Through periodic broadcasts, a given 
5 channel broadcasts a movie repeatedly in cycles. Conventionally there 

are several different schemes for broadcasting in the data-centered 

paradigm. Pyramid broadcasting divides a movie into segments of 

exponentially increasing size and lets each channel broadcast each 
,3 segment repeatedly. The segment is broadcast in the channel at a 

H 10 faster speed than playback speed. Skyscraper broadcasting modifies 

the pyramid approach, using a different distribution of segment sizes 
'■^ and broadcasting at the same speed as playback speed. Skyscraper 

broadcasting places an upper bound on the maximum weight of the 
in segment size. This is done to reduce storage requirements at the client 

'B 15 side (user). The number of multicast channels required does not 

depend on the number of requests from users. Thus the data-centered 

approach appears to be more scalable than the user-centered 

approach. 

The multicast approach to supplying video on-demand from 
20 several users at one time, to some extent, sacrifices special 
requirements of each individual user. The multicast systems usually 
require the client to wait for a certain period before it can be served. 
This is referred to as the startup latency for the services. VCR functions 
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such as pause, fast forward, fast rewind and jump to new location are 
difficult to provide in data-centered multicast systems. Although there 
have been attempts to provide VCR functionality, the solutions offered 
to date have not been able to provide scalability while at the same time 

5 guaranteeing seamless delivery. Typically, as the size of the system is 
scaled up. it becomes increasingly more difficult to provide seamless 
operation. Thus users experience jumpiness or breaks in delivery that 
detract from the enjoyment of the system. The present invention 
proposes a new scheme which can provide VCR functionality in data- 

10 centered multicast video on-demand systems. The scheme is scalable 
and is far more able to guarantee smooth, discontinuity-free delivery. 
The system employs separate buffers at each client, from which media 
content may be played back to support VCR functionality. A loader 
associated with each buffer downloads segments of the video stream 

15 from the video data server under control of a pre-fetch manager that 
intelligently determines what to pre-fetch into the buffer. The pre-fetch 
manager does this by monitoring the playback position pointer and 
controls the pre-fetching operation to maintain the playback position 
pointer within a predetermined range within the buffer. 

20 The system also employs a calculation of feasible points based 

on a set of predefined rules. These feasible points are used in 
determining which operations are performed in a seamless fashion and 
also to identify when seamless operation may not be possible. In the 
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latter case, appropriate user-friendly performance is initiated so that the 
user does not experience undue jerkiness or long delays or gaps in 
media delivery. 

For a more complete understanding of the invention, its objects 
5 and advantages, refer to the following specification and to the 
accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is block diagram of the presently preferred embodiment 
10 for providing VCR functionality; 

Figure 2 illustrates a first broadcasting scenario, demonstrating 
how discontinuity occurs in the case of an unrestricted jump; 

Figure 3 illustrates a similar broadcasting scenario, showing how 
discontinuity can occur in the case of a fastforward action; 
15 Figure 4 illustrates Case 1 of the presently preferred set of rules 

for assessing feasible points; 

Figure 5 illustrates Case 2 of the presently preferred rules for 
determining feasible points; 

Figure 6 illustrates Case 3 of the presently preferred rules for 
20 assessing feasible points; 

Figure 7 is an example showing how the feasible point analysis 
is performed in accordance with the presently preferred embodiment. 
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DESCRIPTION OF THE PREFERRED EMBODIMENT 

A presently preferred embodiment of the system is illustrated in 
Figure 1. The system includes a player module 10 that provides an 
associated user interface 12 by which the user can select among a set 
5 of VCR functions. Illustrated in Figure 1 are the following functions: 
jump backward 14, fast rewind 16, pause 18, play 20, slow motion play 
22, fast forward 24 and jump forward 26. These VCR functions are 
exemplary of the type of functions that may be provided in a consumer 
Q product. Of course, other functions may also be provided, if desired. 

10 For instance, a jog shuttle mechanism may be provided to allow 

^ the user to move forward or backward through successive frames of 

the video content. Also note that a stop function may also be included. 
15 However, in the presently preferred implementation, the pause function 

^ LI 

1^ 18 provides nearly the same functionality as a stop function would. This 

O 15 is so because, unlike in a mechanical VCR, there is no requirement to 

unload the tape from the tape head or to halt the tape drive motors and 
capstan. Nevertheless, if desired, both pause and stop functions may 
be included, in which case the pause function might provide a freeze- 
frame function while the stop function would blank the screen, for 
20 example. 

Player 10 accepts VCR commands from the user interface and 
plays back the video stream through a suitable monitor 30. Player 10 
obtains the video stream from one or more buffers 32. In the presently 




preferred embodiment there is a loader module 34 associated with 
each buffer. The loader module is responsible for interfacing with the 
distribution network 36 to download the required video content, as will 
be more fully described below. 

5 The loader modules are controlled by a manager module 38 that 

is responsible for implementing the selective downloading strategy of 
the system. As will be more fully described below, the manager is able 
to access the playback pointer 40 of player 10. This pointer shows the 
current playback location within the buffer 32 that is currently supplying 

10 the video stream to the player for display on the monitor 30. The 
manager module 38 includes a feasible point calculation module or 
calculation processor 42 that is responsible for assessing which user- 
requested functions may result in discontinuous service. The feasible 
point calculation module thus supplies manager 38 with the information 

15 needed to interpret the user's request in a modified fashion if the 
original request would result in undesirable playback (e.g., jumpy or 
discontinuous playback or long delay). 

When the client wishes to download video segments from a 
broadcast channel on network 36, the manager 38 of the preferred 

20 embodiment causes loaders 34 to load information into the buffers in 
two phases. The first phase is a pyramid phase (unequal segments) 
during which all loaders are used to download information to guarantee 
smooth playback in the normal fonA/ard direction. Once the buffers 32 
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have been loaded to support the initial forward play mode, nnanager 38 
gradually phases the loaders 34 into the equal segment phase. In the 
equal segment phase, some of the segments may be fetched to 
support playback of backward segments (i.e., content that precedes 
5 the current playback pointer). 

The manager selects the channels and segments to be loaded 
based on the current playback segment, as designated by the playback 
pointer 40. The manager 38 assigns priority to each segment based on 
^ 3 its proximity to the current segment and also based on whether loading 

H 10 is in the initial pyramid phase or in the later equal segment phase. 

,^ To illustrate, assume the current segment is k. If k is one of the 

y pyramid phase segments, the first three segments in the forward 

direction (k, k+1, k+2) are assigned the highest priority. If k is one of 
1=1 the equal phase segments, the highest priority segments are the 

C3 15 current segment k and those that immediately precede and follow it (k, 

k+1, k-1). The priorities of the remaining segments are determined by 
their distance from the current segment. The nearer to the current 
segment the higher its priority. In case of ties, the tie is broken in favor 
of the segment in the forward direction. If there are more than three 
20 loaders and buffers, allocation is based on the priority of the segment. 

We will further consider here the special case where there are 
only three loaders and buffers. In this case manager 38 allocates or 
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reallocates the loaders into situations: (a) startup and (b) after 
perfornning a VCR action. 

In the startup situation the playback pointer lies at the boundary 
of the first segnnent to be played. Note that the boundaries of all 

5 segments are also boundaries of the first segment at startup. At this 
boundary both de-allocation and allocation can occur. If a loader 
finishes loading a segment, it is returned to the free loader pool (de- 
allocation). This de-allocation process is voluntary by the loader. 
Allocation can also occur after de-allocation. 

10 During the pyramid phase, the three loaders are allocated to the 

next unassigned segments in line. During the equal segment phase, if 
the play point is in the earlier half of the current segment (the current 
segment being designated segment k), the three loaders are assigned 
to segments k-1, k, k+1. If the play point is in the latter half of the 

15 current segment, the three loaders are assigned to segments k, k+1. 
k+2. If the contents of the segment to be played is already in the buffer 
no loading occurs for that segment. Later downloading segments may 
overwrite earlier segments already in the buffer. However, if the 
playpoint is in to-be-overwritten segment in the buffer, the manager 38 

20 prevents it from being ovenA/ritten beyond the playpoint. We call this 
playpoint protection. 

In the second situation (after every VCR action is performed) a 
somewhat different sequence proceeds. During the pyramid phase, the 




manager checks whether the loaders are assigned to k, k+1 , k+2. If 
this is the case, no actions are taken. Otherwise, the manager will 
enforce preemptively the assignment. During the equal segment 
phase, if the playpoint is inside the buffer, no actions are taken. The 
5 relative position of the playpoint is adjusted when the downloading 
point (channel broadcast point) comes to the boundaries of the equal 
segments. If the playpoint goes outside the buffer (the current segment 
assumed to be k), the manager reallocates the loaders to segments k, 
k+1 and k-1 . This may cause an involuntary de-allocation of loaders. 

10 The manager 38 of the preferred embodiment controls the 

loading of buffers 32, based on the playback pointer 40, striving to 
maintain the playback pointer within a pre-determined range within the 
buffer. In the presently preferred embodiment, the manager causes 
information to be fetched and stored in the buffers so that the playback 

15 pointer remains at or near the center of the buffer after the initial 
pyramid phase loading is completed. Doing this allows the system to 
provide continuous VCR functionality with a very high probability that 
the user's request can be smoothly carried out. In contrast with other 
schemes, the present system empowers the client to actively pre-fetch 

20 nearby frames around the playback point and to locally manufacture 
the contents required to implement most VCR actions by appropriately 
accessing the local buffers 32. 



9 




To account for situations in which a user's VCR command may 
not be feasible, manager 38 includes a feasible point calculation 
module 42. The preferred implementation employs a set of rules to 
decide whether a given destination point is feasible or not, and how to 
5 respond accordingly. To provide high quality VCR functionality and 
seamless playback, the system strives to guarantee that the user can 
jump to a desired destination point p and then resume normal playback 
to the end of the movie without discontinuity. Given the particular 
channel broadcasting situation and the buffer conditions at the client, 

10 not all points are feasible points. For example, as illustrated in Figure 2, 
an unrestricted jump can lead to discontinuities of later playback even if 
there is no subsequent VCR action. As Figure 2 illustrates, assume 
that a user issues a VCR action to jump to position c of segment k 
outside of the client's buffer and that the channel k happens to 

15 broadcast at point c. If the jump is allowed, after an elapse of time t, the 
buffer will only have Ck Ok and Ck+i d, however the client needs to 
playback from ek (or bk+i) to Ck+i, which is not available and results in 
discontinuous playback. 

Even if the video frame contents are in the buffer, some VCR 

20 actions can lead to discontinuity after normal play is resumed. Figure 3 
illustrates this. In Figure 3 a fastforward action is initiated. Assume that 
the channel broadcasting point is Cj for channel 1. The contents of 
channel k are in the buffer and contents of channel k+1 are not in the 




buffer. The current playback point is bk. If a fastforward command is 
issued with length of ek ek, all the contents are in the buffer. Assume 
that the fastforward of this length takes time t. If the system performs 
this action to the full length, it will take time t to the playback position of 
5 ek. At this point, only bk ek and Ck+i d in the buffer, but bk+i Ck+i is 
needed to continue normal play and is not available. 

To address the issues illustrated in Figures 2 and 3, the feasible 
point calculation module determines whether a given point is feasible 
Q or not and then determines how to find the nearest point that is 

10 feasible. The presently preferred embodiment distinguishes three 
^ "j; following cases according to the relative size of the segments involved. 

Assume that the size of segment i is Sj. The beginning position 
and end position of segment i and bj and ei, respectively. We assume 
|S that bj = 0 for all 1 <_ i < K. At any time each channel is broadcasting a 

P 15 specific frame in the segment. This point is denoted as Cj and we have 

bj <_Ci <_ei. 

If the destination point p is located at or before the channel point 
Ci, we call the segment containing the desired destination current 
segment and we assume it is segment k and broadcast in channel k. 
20 First we give the rules for this case. After that, we consider the cased in 
which the destination point p is located after the channel point q. 



• Case 1 (Figure 4): Sk = Sk+i. This is the case in 
which the size of the current segment is equal to the size of the next 
segment. It is abbreviated as (x. x) case. 

If pck is in the buffer, then p is feasible; 
5 otherwise, the later nearest feasible point is the point q such that qCk 
are in the buffer with the smallest *q value. 

• Case 2 (Figure 5): Sk+i = 2 * Sk and Sk+2 = Sk+i. This 
is the case in which the size of the current segment is half of the size of 
the next segment and the next two segments are of equal size. It is 

10 abbreviated as (x, 2x, 2x) case. 

case 2.1 Ck = Ck+i. This is case in which the 
broadcasting position of channel k is the same as channel k + 1 , or 
they are left aligned. 

If pCk and bk+iCk+i are in the buffer, then p is 
15 feasible: otherwise, if bk+iCk+i is in the buffer, the later nearest feasible 
point is the point q such that qCk are in the buffer with the smallest q 
value; if bk+iCk+i is not in the buffer, the later nearest feasible point is 
the point q such that qck+i are in the buffer with the smallest q value; 

case 2.2 Ck ^ Ck+i. This is case in which the 
20 broadcasting position of channel k is not the same as channel k + 1, or 
they are left aligned. 
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If pck is in the buffer, then p is feasible; otherwise, 
the later nearest feasible point is the point q such that qck are in the 
buffer with the smallest q value. 

• Case 3 (Figure 6): Sk+i = 2 * Sk+i and Sk+2 = 2 * Sk+i. This 
5 is the case in which the size of the current segment is half of the next 
segment and the size of next segment is in turn half of the size of its 
next segment. It is abbreviated as (x, 2x, 4x) case. 

case 3.1 Ck = Ck+i= Ck+2. This is case in which the 
=■5 broadcasting position of channels k, k + 1 and k + 2 are the same, or 

J 10 they are left aligned. 

: ^ If pCk, bk+iCk+i and bk+2Ck+2 are in the buffer, then p 

:^ is feasible; otherwise, if bk-t-iCk+i and bk+2Ck+2 are in the buffer, the later 

in nearest feasible point is the point q such that qCk are in the buffer with 

i n the smallest q value; if bk+2Ck+2 is in the buffer and bk+iCk+i is not all in 

'3 15 the buffer, the later nearest feasible point is in the point q such that 

qCk+1 is in the buffer with the smallest q value: if bk+iCk+i is not in the 

buffer, the later nearest feasible point is the point q such that qCk+2 is in 

the buffer with the smallest q value: 

case 3.2 Ck = Ck+i ^ Ck+2. This is case in which the 

20 broadcasting position of channels k, k + 1 are the same, but not the 

same as that of channel k + 2. 

If pCk, bk+iCk+i are in the buffer, then p is feasible; 

otherwise, if bk+iCk+i is in the buffer, the later nearest feasible point is 
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the point q such that qCk is in the buffer with the smallest q value; if 
bk+iCk+i is not all in the buffer, the later nearest feasible point is the 
point q such that qck+i is in the buffer with the smallest q value: if 
bk+iCk+i is not in the buffer, the later nearest feasible point is the point q 
5 such that qCk+1 is in the buffer with the smallest q value. 

case 3.3 Ck ^ Ck+i ^ Ck+2. This is case in which the 
broadcasting position of channels k + 1 , k + 2 are the same, but not the 
same as that of channel k. 

If pck, bk+2Ck+2 are in the buffer, then p is feasible; 
10 otherwise, if bk+2Ck+2 is in the buffer, the later nearest feasible point is 
the point q such that qCk is in the buffer with the smallest q value; if 
bk+2Ck+2 is not all in the buffer, the later nearest feasible point is the 
point q such that qCk+2 is in the buffer with the smallest q value. 

case 3.4 Ck ^ Ck+i ^ Ck+2. This is case in which the 
15 broadcasting position of channels k, k +1 and k + 2 are all different, or 
they are ail right-aligned. 

If pCk is in the buffer, then p is feasible; otherwise, the later 
nearest feasible point is the point q such that qCk are in the buffer with 
the smallest q value. 
20 If the destination point p is located after the channel point Cj, the 

next segment to the one that contains the desired destination is called 
the current segment. We assume it is segment k. In this situation, pCk 
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means pek.i and bkCk. After this modification, we can use the above 
rules. 

Figure 7 shows an example how to determine the feasible point 
in this case. Assume the destination point is p, which is later than the 

5 broadcasting point Cy. So the current segment should be k = 8. Since 
the segment size of current segment is half next segment and next two 
segments are of equal size, this is the case 2.1 of the above rule. As 
stated above, we use pck to represent pej and bsCs. According to the 
rule 2.1, p is a feasible point in case (a). In case (b), p is not a feasible 

10 point and the nearest feasible point is d because bk+iCk+i is in the buffer 
and d is the smallest value such that dCk is in the buffer. 

The feasible point calculations, described above, allow the user 
to specify an arbitrary destination within the video-on-demand data 
stream. The system automatically adjusts the destination to a nearby 

15 feasible point, if the point requested by the user is not feasible. Thus, 
when the destination is not in the buffer, only those destination frames 
that are being broadcast at each channel are available immediately. 
The feasible point calculation module assesses what is possible and 
selects the nearest frame among those available as the adjusted 

20 destination if the requested destination cannot be met. If the feasible 
point calculation module determines that the requested frame is 
feasible, we call this an allowed destination. If the feasible point 
calculation module determined that the requested frame cannot be met 




without discontinuity, it substitutes a different frame that can be met. 

We call this the adjusted destination. 

One desirable property of the destination, either allowed or 

adjusted, is that once the client resumes normal play from this 
5 destination, the client is able to playback to the end of the video without 

experiencing interruptions, provided there are no further VCR actions. 
In developing an actual embodiment of the invention, the system 

designer may wish to specify the number of buffers used at each client. 

To implement a robust VCR-oriented scheme, two conditions should be 
10 preferably met: 

(1) If the destination segment is not in the buffer, and 
we still require that we can always select the frame being broadcast at 
this channel as the destination, the segments sized must be equal to 
the size of the next segment in order to guarantee that the client can 

15 playback the next segment when it finishes playing the current 
segment. 

(2) The sizes of all segments beginning from the latter 
of these two equal segments must satisfy the continuity condition that 
guarantees smooth playback of the remainder of the video will be 

20 possible, assuming the client can download from m channels 
simultaneously. 
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Equation 1 below presents the function f(n) that will satisfy the 
above two conditions. The equation assumes that a client can 
download from m channels simultaneously. 

Equation 1 

As an example, we give below the series generated by f(n) with 

m = 5: 

1, 2, 4. 8, 16. 16. 32. 64. 128. 256. 256. 512. 1024. 2048. 
4096,... 

In designing a system, the value of m (simultaneously available 
channels) places a minimum requirement on the bandwidth needed at 
each client. Considering the heterogeneity of the client, we like m to be 
small. On the other hand, in order to pre-fetch nearby segments of the 
current playback segment, clients download both the next segment for 
forward VCR action and the previous segment for backward VCR 
action. These segments are fetched in addition to the current segment. 
Thus in the presently preferred embodiment the value of m is 
preferably 3 or greater. If fewer than 3 channels are available 
simultaneously, then the system will have to sacrifice in supporting 
foHA^ard or backward VCR functionality. Thus in the preceding example, 
we have used 
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m = 3 to illustrate both forward and backward VCR functionality. Of 

course, in a practical implementation, the value selected for m can be 

greater than 3 while still preserving the benefit of supporting both 

forward and backward action. 

5 Given that the series dictated by Equation 1 is monotonically 

increasing and is bounded by f(u) = f(K), we determine the buffer 

requirement for a client to be the size of the largest segment minus one 

size unit. Thus the buffer requirement may be expressed as a function 

of f(n) as follows: 

10 Equation 2 

f(u)xL 
Buffer = . 

S..,/<") 

In operation, when a client downloads video segments from the 

m 

fpi broadcast channels, we shall assume that at the outset no VCR 

□ 

□ functions are invoked and the video is to proceed at the beginning of 

15 the program. At the beginning, three loaders wait until the boundary of 
the first segment is detected. This waiting time is the startup latency 
and the maximum waiting time will be the time required to playback the 
first segment. The first loader begins to download from the first channel 
and contents of its buffer are played. The other two loaders are 
20 assigned to the second and third channels, respectively. Depending on 
the relative positions of each channel, the loader may download from 
the second channel at the beginning or at the end of the first segment. 
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Similarly, the loader may download from the third channel at the 
beginning or end of the second segment. When the contents of the 
buffers are played they are immediately discarded. Whenever a loader 
finishes downloading the assigned channel, it is assigned to the next 

5 immediate unassigned channel. It begins downloading from the 
channel when the length of the contents in its buffer is less than the 
assigned channel segment size. This guarantees that downloading of a 
segment is delayed as much as possible to save buffer space, but it 
also guarantees smooth playback of that segment. 

10 The foregoing system is thus able to provide smooth, continuous 

playback while supporting all popular VCR functions. While the 
invention has been described in its presently preferred embodiments, it 
will be understood that the invention is capable of modification without 
departing from the spirit of the invention as set forth in the appended 

15 claims. For example, the number of buffers employed at a client 
location can vary. Also, the number of loaders used to service the 
buffer population can also vary. While a one-to-one correspondence 
between buffers and loaders is presently preferred, some 
implementations may be able to provide adequate throughput with 

20 fewer loaders than buffers. 
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